Python WSGI Apps + Gunicorn HTTP Server + Nginx Webserver

2017년 11월 15일 수요일

오후 4:34

참고링크: https://www.digitalocean.com/community/tutorials/how-to-deploy-python-wsgi-apps-using-gunicorn-http-server-behind-nginx

 

개요

파이썬으로 어플리케이션을 만들었다.

웹을 통해서 서비스를 하려면 어떻게 해야할까?

초 간단버전으로 정리해보면

1) 파이썬 어플리케이션을 만들고

2) 이것을 구동할 웹 어플리케이션 서버와 연결시키고

3) 이왕이면 그 앞에 (=바깥세상과의 연결통로로) 웹서버를 둔다

 

아래 그림들은 개념을 잡기위해 구글링해 가져온 것들

 

0) 기술스택 참고

- LAMP: Linux Apache MySQL PHP

- LEMP: Linux Nginx MySQL PHP

 

1) 맨 앞에서 request 를 받아들이는게 Nginx 웹서버 (보통 Apache 또는 Nginx)

- Static 한 것들을 처리하거나

- DDOS 등을 대응하거나

- 기타등등 많은 일을 한다.

2) 이처럼 단순 작업이 아닌 것을 처리하는게 웹 어플리케이션 서버

- Gunicorn 또는 uWSGI 가 유명

- Gunicorn 은 간편하고 탄탄하다. uWSGI는 기능막강하고 대세이다 정도로 요약

3) 웹어플리케이션 서버를 통해 우리가 개발한 웹앱을 구동시킨다

- 그냥 코딩할 수도 있고

- (파이썬의 경우) Flask, Django 와 같은 Framework 를 이용해서 좀더 간편하게 개발할 수도 있다

관련 이미지

 

1) 외부에서 Request 가 온다

2) Nginx 는

- Static 한 것들은 알아서 처리하고

- 웹앱서버가 처리할 것은

- 로컬호스트의 특정 포트로 보내준다

3) 그러면 Gunicorn 이 받아서

- Flask (그림의 고추)로 구현된 앱에서 처리

Navigateur Serveur HITP Serveur WSGI APP Ex: nginx Ex: gunicorn Ex: une app bottle, django, pyramid...

 

1) 외부 웹브라우저에서 HTTP로 Request를 날리면

2) Nginx 같은 웹서버가 Socket 을 통해서 WSGUI 로 보냄

- WSGI: Web Server Gateway Interface

3) 그러면 Gunicorn 과 같은 WSGI Server 가

- WSGI 방식으로 앱과 연동

 

* Gunicorn 이 Nginx 웹서버와 App 사이에서

- Socket, WSGI 와 같은 통신방법으로

- 업무를 처리한다고 보자

 

App •corn ost tatic Assets Socket ebse GNX) Browser

 

이 그림도 마찬가지다

1) Nginx 는 웹서버이고 Static Asset을 처리

2) Guncorn을 통해 탑재된 Django 앱과 통신

nginx gunicorn에 대한 이미지 검색결과

 

Gunicorn, uWSGI 같은 WSGI server에

- Django 와 같은 앱이 탑재된다

 

 

Gunicorn

 

- stand-alone WSGI web application server

- 기본적으로 다양한 프레임워크를 지원한다 (with adapters)

- 엄청 쉬워서 개발시의 서버를 쉽게 대체할 수 있다.

 

Ruby Application을 위한 Unicorn Web server 와 상당히 유사하며,

pre-fork model 이다. = central 의 Gunicorn master가 worker의 관리를 한다. (creating sockets, bindings, etc)

 

Gunicorn Server Highlights Runs an WSGI Python web application (and framework) Can be used as a drop-in replacement for Paster (Pyramid), Django's Development Server, web2py etc. Comes with various worker types and configurations Manages worker processes automatically HTTP/I.O and HTTP/I.I (Keep-Alive) support through synchronous and asynchronous workers Supports SSL Extensible with hooks Python 2.6+ and 3.x support

 

 

 

Nginx

 

- 고성능 웹서버 / (reverse) proxy

- 가볍고 쉽고 확장까지 쉽다 (add-ons, plug-ins)

- 거의 무제한의 request를 handling 가능하다.

 

* 리버스 프록시(reverse proxy)

: 프록시 서버가 사설 네트워크(private network) 상의 서버들 바로 앞단의 프론트엔드(front-end)에 위치하여 서버들을 제어하고 보호

 

Nginx를 application server 앞에서 reverse-proxy로 사용하면?

 

- (Gunicorn을 포함한) application server 들도 static file 를 제공하고 response 할 수 있다.

- 하지만 static 들 (javascript, css, images, etc)은 그냥 (reverse-proxy) server 가 처리하게 하는게 좋다.

- 이런 경우 Nginx 는

1) static files 를 다루고

2) connection을 managing 한다. (requests)

= 앱서버의 부담을 덜어준다

 

많은 connection을 동시에 감당하는 딴딴한 (robust) 구조로 만들려면 여러 서버에 분산해놓으려 할 것이다. = VPS

- 그리고 이런 VPS 앞에 Nginx 와 같은 reverse-proxy server를 두려 할것이다.

* VPS (Virtual private server) : http://library.gabia.com/infrahosting_3

 

고객1 고객2, 고객3, 서버 자원 서버 웹호스팅 . 고객30 고객1 서버 자원 고객2 서버 자원 서버 VPS 호스 팅 고객3 서버 자원 물리적 서버 자원을 다수의 사용자가 공용 사용 물리적 서버 안의 가상 서버를 각각 독립 사용 (서버호스팅과 비슷)

 

 

간단한 구조는 아래와 같다.

 

- Client가 request 를 날리면

- Nginx가 받아서 아래의 worker 들에게 나눠주는 것이다. (Port들이 다른걸로 구분)

Client Request e. 1: se81 e. 1: se82 e. 1: se83 ---- > Nginx (Reverse-proxy) App. App. App. Server Server Server 11. 111. 127. 127. 127. e. e. e.

 

 

여기서부터 실제로 해보자

실습 초간단 정리버전

웹콘솔에서 VM 생성

- VM 만들기

sudo apt-get update && sudo apt-get install python-pip

sudo apt-get install virtualenv

mkdir my_app && cd my_app

virtualenv my_app_venv

source my_app_venv/bin/activate

- 폴더 + 가상환경 생성 및 구동

sudo apt-get install nginx
pip install gunicorn

- 웹서버 nginx 설치

- 웹어플리케이션서버 gunicorn 설치

vim myapplication.py

gunicorn --workers 4 --bind 127.0.0.2:8080 myapplication

파이썬 앱 만들고 실행

 

 

 

 

 

 

 

 

 

VM 만들기

 

us -02n 1 - b

Firewalls Allow Allow HTTPS tranc

1) 이름은 Nginx

2) 지역은 us-central1-b  (지역마다 가격이 다를 수 있다)

3) VM의 HTTP port 80을 열어줘야 외부에서 들어올 수 있다

 

 

폴더 + 가상환경 생성 및 구동

 

- 웹콘솔에서 SSH로 접속

Name A nginxl Zone us-centrall-b Recommendation Internal IP ID 128.02 External IP 104.198_203.36 Connect

 

sudo apt-get update && sudo apt-get install python-pip

sudo apt-get install virtualenv

1) pip 설치

2) virtualenv 설치

mkdir my_app && cd my_app

virtualenv my_app_venv

1) 폴더 만들고 들어가서

2) 가상환경 만들기

source my_app_venv/bin/activate

1) 가상환경 동작시키기

* 나올때는 deactivate

 

Gunicorn, Nginx 도 인스톨

 

* virtualenv 를 쓰려면 pip로 인스톨하는게 맞다.

sudo apt-get install nginx

1) 설치후 브라우저로 VM의 external IP로 들어가면 nginx 화면을 볼 수 있다.

pip install gunicorn

1) Web Application Server 를 동작시킬 gunicorn 실행

 

[참고] firewall rules 확인

VM의 설정 (Edit 화면)

Firewalls V Allow HTTPtraffc Allow HTTPS tramc Network tags http-server O

 

적용된 tag를 가진 Firewall rule

default-allow-http Network default Priority 1000 Direction Ingress Action on match Allow Targets Target tags Source filters IP ranges Protocols and ports tcp:8C http-server

 

 

 

* [참고] apt-get 과 pip의 차이점은?

간단하게 이야기하면 - 특정 버전의 패키지를 특정 환경 안에만 (=virtualenv) 설치하려면 pip

apt-get:

Single version of package

Limited number of modules

pip:

All modules

Can select which package versions to install

자세한 버전

: https://askubuntu.com/questions/431780/apt-get-install-vs-pip-install

PyPI is the Python Package index — repository of python modules. pip is used to download and install packages directly from PyPI_ PyPI is hosted by Python Software Foundatiom It is a specialized package manager that only deals with python packages apt-get is used to download and install packages from Ubuntu repositories which are hosted by Canonical. Some of the differences between installing python packages from apt-get and pip are as follows: Canonical only provides packages for selected pvthon modules Whereas, PyPI hosts a much broader range of python modules. So, there are a lot of python modules which you won't be able to install using apt-get Canonical only hosts a any package (generally the latest or the one released in recent past). So, with apt-get we cannot decide the version of python-package that we want. pip helps us in this situation. We can install of the package that has previously been uploaded on PyPI_ This is extremely helpful in case of conflict in de ndencies apt-get installs python modules in s stem-wide locatio We cannot just install modules in our project vinualenv. pip solves this problem for us If we are using pip after activating the virtualenv, it is intelligent enough to only install the modules mentioned in previous point; if there is a version of a particular python package already installed in system wide location, and one of our project requires an older version of the same python package, in such situations we can use virtualenv and pip to install that older version of python package without any conflicts. As @Radu Rädeanu pointed out in this answer, there would generally be difference in names of packages as well. Canonical usually names Python 2 packages as python-<package name> and Python 3 packages as python3-<package name> . Whereas for pip we generally just need to use <package name> for both Python 2 as well as Python3 packages. Which one should you use: Both apt-get and pip are mature package managers which automatically install any other package dependency while installing You may use anyone as you like However, if vou need to install a panicular version of pvthon-packaqe. or install the package in a virtualenv or install a eackage which is only hosted on PyPl; only pip would help vou solve that issue. Othervvise, ifyou don't mind installing the packages in system wide location it doesn't really matter whether you use apt-get or pip

 

 

* [참고] Google Cloud Shell 에서 깔면 날아가려나?

- 1시간 안쓰면 terminate 되고

- $HOME 디렉토리 외부의 변경사항은 다 날아간다

- 링크: https://cloud.google.com/shell/docs/limitations

The virtual machine instance that backs your Cloud Shell session is not permanently allocated to a Cloud Shell session and terminates if the session i inactive for an hour After the instance is terminated, any modifications that you made to it outside your SHOME are lost.

 

_

 Gunicorn 으로 파이썬 앱 실행

 

간단한 파이썬앱을 만들어서 Gunicorn으로 실행시켜보자

(my_app_venv) nicenookc,xsgi: $ cat myapplication.py def application (env. start_response): start_response('2ØØ OK', 'Content—Type', 'text/html')]) return ["Hello"]

 

gunicorn --workers 4 --bind 127.0.0.2:8080 myapplication

- 우리가 만든 myapplication.py 앱을 실행하고

- master process를 하나 실행한 다음 worker process를 4개 생성하였다 = pre-fork

 

- (중요) 현재 gunicorn이 실행된 VM의

- 0.0.0.0 으로 설정한다면어떤 내부 아이피로 들어오든 (=0.0.0.0)

- 혹은 특정하여 127.0.0.2의  8080 포트로 들어오는 놈은 이걸로 처리하겠다는 것이다.

* application 이라는 함수명은 default라 생략가능한것인가 보다.

- 만약 함수명이 myapp() 이라면 아래와 같이 gunicorn 실행

gunicorn --workers 4 --bind 127.0.0.2:8080 myapplication:myapp

(my_app_venv) : "$ gunicorn - -workers 4 --bind 11-20 oe:el : 11-20 oe:el : 11-20 oe:el : 11-20 oe:el : 11-20 oe:el : 11-20 oe:el : 11-20 oe:el : [2017- [2017- [2017- [2017- [2017- [2017- [2017- 03 03 03 03 03 03 03 +eaae] +eaae] +eaae] +eaae] +eaae] +eaae] +eaae] [9204] [9204] [9204] [9208] [9209] [9210] [9211] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] Starting gunicorn 19.7.1 Listening at: http://127 Using worker: sync Booting worker with Booting worker with Booting worker with Booting worker with pid: pid: pid: pid: 127.0.0.2:8080 myapplication .e.a.2:808a (9204) 92e8 92e9 921e 9211

 

[참고] workers

- 의미는 같은 기능을 하는 프로세스를 여러 개 띄운다는 것이다.

- 적정 worker 개수 공식은 아래와 같다.

1) 하나의 CPU에 두개의 worker를 할당해준다

2) 하나의 worker가 CPU와 일하다가 I/O쪽을 처리하면 CPU는 놀게된다

- 이때 다른 하나의 worker 가 CPU를 사용하라는 의미이다

(2 Workers CPU Cores) For For For core cores - 4 cores -

 

 

그런데 VM의 External IP를 통해 8080 포트로 진입하면 접근이 안된다

 

해법 - 이라기 보다는 방법은 2가지가 있다

1) tcp:8080 포트를 열어주거나

(오류수정) 이대로는 안된다. gunicorn 에서 --bind 0.0.0.0:8080 으로 해줘야 외부포트 8080을 열어줬을때 들어온다

2) 이미 열려있는, 그래서 Nginx 가 쓰고있는 tcp:80 포트로 들어온 것을

- Nginx 가 8080 포트로 redirection 해주는 거다.

 

Firewall (방화벽) 의 개념을 익힐겸 잠시 샛길로 돌아가보자.

 

1) Firewall rule - 방화벽 규칙을 하나 만든다음

- tcp:8080 을 허용한다

- tag 는 http-8080 으로 한다

2) 이것을 내 VM에 적용해주면 된다

Google Cloud Platform VPC network VPC networks External IP addresses Firewall rules Routes VPC network peering Shared vpc CPIOO • Create a firewall rule Firewall rules control incoming or outgoing traffic to an ins incoming tramc from outside your network is blocked. Lea Name O wsgi-8080 Description (Optionan allow 8080 port Network O default Priority Priority can be O - 65535 Check priority of other firewall rules 1000 Direction of traffc • Ingress Egress Action on match • Allow Deny Targets Specified target tags Target tags http-8080 0 Source filter IP ranges Source IP ranges 0.0/0

 

Firewall rule - 방화벽 규칙을 만들었다.

 

1) 이름은 wsgi-8080

2) Ingress 들어오는 놈들 처리

3) http-8080 이라는 태그를 붙이기만 하면 방화벽 규칙 적용됨

 

마지막으로 적용할 프로토콜/포트는 tcp:80

- 왼쪽에 다 담기 길어서 여기에 복붙

Protocols and ports Allow all • Specified protocols and ports tcp80 Create Cancel

 

그리고는 적용할 내 VM 에서 Network tags에

- http-8080만 추가하면 끝

- tcp:80 = http-server 는 이미 적용되어 있음

- 그러니깐 Nginx 가 access 된 것임

 

Network tags http-server http-8080 0

 

 

이렇게 해주고 다시 내 VM의 External IP 의 8080 포트로 들어가보면 연결된다!

- 현 시점에 두 개의 웹서버(?)가 돌고 있는 셈이다

- 즉, gunicorn 도 웹서버로 쓸 수 있다. 하지만 Nginx 의 여러 장점들을 쓰려고 양보하는 것이다

 

CD - TickTi Apps Hello X Compute ET X @ temp read later

 

 

현시점에서 중간 정리

 

1) Nginx 와 Gunicorn 을 설치했고

2) Nginx 는 80 포트로 들어오는 HTTP 요청을 받아서 처리하는 웹서버 역할을 하고 있고

3) Gunicorn 은 127.0.0.2 IP의 (모든 IP라면 0.0.0.0 으로), 8080 포트로 들어오는 모든 HTTP 요청을 받아서

- 특정 어플리케이션이 처리하도록 하였으며

- 어플리케이션은 pre-fork 하여 4개를 두었다.

* 위에 샛길로 빠진 방화벽 옵션은 제거하자

 

GCP의 방화벽 이야기 조금 더

 

- VM에 적용된 8080 방화벽을 제거하면 Gunicorn 으로 구동되는 웹서버(?)로는 더 이상 접근이 안될까?

- Firewall rule 만 제거해도 Gunicorn 8080 포트가 동작하지 않는게 맞다.

- 그런데 동작함. @_@

- 알고보니 http-8080 이라는 같은 이름의 태그를 적용한 firewall-rule 이 있었다. (정책이 좀 이상함)

- 즉, firewall1, firewall2 라는 다른 이름의 firewall rule 이 같은 포트를 열어주고, 같은 태그를 사용하는 경우도 가능하다는 것

 

 

 

Nginx 에서 redirection 해주기

 

/etc/nginx/nginx.conf 만 만져주면 된다.

 

1) gunicorn 으로 웹서버 실행

 

- 127.0.0.1:8080 으로 실행하게 해둠

I ugz ocugz aaggz Baggz (vaggz) I OLMS : 'ah 'OM [ liugz.] [Diugz.] [aaggz.] [Baggz.] [vaggz.] [vaggz.] I [vaggz] Dl BI-1 1-1 ICE] $ Iaae,fU] V M- OBDB: I q- $ Dl BI-1 1-1 ICE] Dl BI-1 1-1 ICE] Dl BI-1 1-1 ICE] Dl BI-1 1-1 ICE] Dl BI-1 1-1 ICE] Dl BI-1 1-1 ICE] (nuan-aae-6U]) vaggz [l] (nuan-aae-6U])

 

2) sites-available / sites-enabled

 

/etc/nginx/sites-available 폴더

- 처음엔 templete로 default 라는 파일 하나만 있음

- 모든 서버설정 파일들을 여기에 만들어둔다.

- 하지만 이시점에는 nginx 서버와는 아무 연관없음

 

/etc/nginx/sites-enabled 폴더

- sites-available 폴더에서 실제 설정하고싶은 서버파일만 여기로 symlink 한다

* symlink 하면

- 여기에 파일이 있는것처럼 동작하지만 실제파일은 sites-available에 있는거다.

- 여기서 symlink 한 파일을 삭제해도 원본은 삭제되지 않는다.

- ngnix.conf 파일에서는 이 폴더의 파일들을 include 하여 설정에 적용하게 된다.

- 결과적으로 sites-available 폴더의 서버 설정 파일들중 원하는 설정만을 symlink를 통해 enable / disable 하는 셈

 

/etc/nginx/nginx.conf 파일

- nginx 서버의 메인 설정파일

- include /etc/nginx/sites-enabled/*; 명령으로 서버정보를 끼워넣는다. (include)

/etc/nginx/sites-available templetee default 71 Oil nginx /etc/nginx/sites-enabled symlink -sites-available -#30118 symlink symlink sites-availableC\1 91-É-7-lcf symlink 01 include Sites-available symlinkæ include enable / disable /etc/nginx/nginx.conf nginx include /etc/nginx/sites-enabled/*; & (include)

 

 

- 아래는 가벼운 실험

1) sites-available / sites-enabled 모두 default 라는 파일이 있다.

2) 사실 sites-enabled의 default 파일은 sites-available의 default 파일의 symlink 이다.

3) 따라서 sites-enabled 의 default 파일을 지워도 sites-available 의 파일은 지워지지 않는다.

(my _ (my _ $ Is (my _ rm: (my _ (my _ $ Is (my _ $ Is aoo_ aoo_ aoo_ aoo_ venv) venv) venv) venv) nicewook@wsgi nicewook@wsgi nicewook@wsgi nicewook@wsgi $ cd ../si tes-enabl ed/ cannot remove 'default'. Permission aoo_venv) aoo_venv) aoo_venv) den ed $ sudo rm default ../sites-avai lable/

 

 

- 외부 IP의 80 포트로 들어오는 request 는 nginx 로 오게된다

- 이걸 받아서 내부아이피 127.0.0.1의 8080 포트로 보내게 하는거다.

 

3) nginx 와 gunicorn 연결

 

1) sites-available 폴더에서 template 역할을 하는 default 를 복사해서 gunicorn_server 를 만들고

sudo cp ../sites-available/default ../sites-available/gunicorn_server

2) 그걸 수정한다음

sudo vim ../sites-available/gunicorn_server

3) sites-enabled 폴더에 symlink 를 만든다

sudo ln -s ../sites-available/gunicorn_server ./gunicorn_server

(my _ (my _ (my _ (my _ In: (my _ (my _ $ Is aoo_venv) aoo_venv) aoo_venv) aoo_venv) fai led to aoo_venv) aoo_venv) nicewook@wsgi nicewook@wsgi nicewook@wsgi nicewook@wsgi create symbolic link nicewook@wsgi nicewook@wsgi $ sudo co ./si tes-avai labl e/default ./si tes-avai lable/gun corn_server ./si tes-avai lable/gun corn_server ./si tes-avai lable/gun corn_server ./sites-avai lable/gunicorn_server ./gunicorn_server ./gunicorn_server' Permission denied ./sites-avai lable/gunicorn_server ./gunicorn_server gun corn_server

 

뭘 수정했냐면

127.110.

 

이렇게 했더니 에러발생

sudo service nginx reload Job for nginx. service failed because the control process ee "systemctl status nginx. service" and "journalctl -xe" sudo service nginx stop sudo service nginx start Job for nginx. service failed because the control process ee "systemctl status nginx. service" and "journalctl -xe" exited with error code. for details. exited with error code. for details.

 

에러 내용을 보려면 아래와 같이 치면 된다고 하는데

systemctl status nginx.service

journalctl -xe

 

nginx -t -c /etc/nginx/nginx.conf 이걸 치면 문법적 오류 체크하는데 더 좋다

 

- 내 문제는 마지막에 세미콜론(;)을 안넣은것과 앞에 http:// 를 붙이지 않은 것이었다.

 

—s signal —p prefix —c filename rectives Print help. Print versiorm Print NGINX version, compiler version and configure parameters. Dont run, just test the configuration file. NGINX checks configuration for correct syntax and then try to open files referred in configuration. Suppress non-error messages during configuration testing. Send signal to a master process stop, quit, reopen, reload. (version 07 53) Set prefix path (default ,/usr/l nx/)_ (version 07 53) Specify which configuration file NGINX should use instead of the default Set global directives (version 07 4)

 

* upstream은 생략합니다

 

4) nginx 재시작

 

- sudo service nginx reload 해주면 재시작 해준다

- 이제 브라우저로 들어가보면 nginx 의 시작화면이 아니라 gunicorn을 통해 실행한 myapplication.py 파일이 실행될 것이다

- 참고로

nginx 시작: sudo service nginx start

nginx 정지: sudo service nginx stop

 

 

Gunicorn 4 worker test

 

workers 에 따른 request 처리를 테스트 해보자

 

테스트 툴

- boom: https://github.com/tarekziade/boom

- Google Cloud Shell 에서 pip install boom 으로 설치함. 안되면 위 링크 참고해서 install

 

테스트하기

boom http://104.198.203.36 -c 10 -n 100

1) 특정 ip로 request 폭탄을 날려라

2) -c: 동시에 (concurrency) 10개씩

3) -n: 총 100개를 날려라

 

테스트1 결과

 

- boom http://104.198.203.36 -c 10 -n 100

 

http://lß.198.2B .36 Server Software: nginx/I.Iø.3 Running GET http://1ø4.198.2e3.36:8e Running Iøø queries - Results - Successful calls Total time Average Fastest Slowest Amplitude Standard deviation RPS BSI le concurrency 3.1833 e. 3141 ø.3e72 e. 33e5 ø.ø233 ø .øø6ø91 Status codes - code 2øø - Legend RPS: Request Per Second BSI: Boom Speed Index times. http://lß.198.2B .36 -c 10 -c 10 Server Software: nginx/I.Iø.3 Running GET http://1ø4.198.2e3.36:8e -n løø løøx Done -n løø løøx Done Running Iøø queries - Results - Successful calls Total time Average Fastest Slowest Amplitude Standard deviation RPS BSI le concurrency 3.1835 e. 314ø ø.3e71 e. 3297 ø.ø226 ø. øe5828 Status codes - code 2øø times. RPS : - Legend Request Per Second Boom Speed Index

 

이거만 봐선 모르지만

- 위에건 gunicorn worker 가 1개

- 아래건 gunicorn worker 가 4개인 상황이다.  

 

1) 둘 다 100번의 request 에 대해 모두 code 200 = OK

2) 둘다 시간차이도 거의 없다.

 

겨우 100개의 요청이라서 별 차이가 없는 것으로 보인다.

- 어짜피 CPU 개수는 한정되어 있으니.

 

참고. 만약 gunicorn 서버를 꺼버린다면? (Ctrl+C)

당연히 에러가 리턴된다. code 502 = Bad Gateway - 아예 경로에 접근이 안되는 것

http://lß.198.2B .36 Server Software: nginx/I.Iø.3 Running GET http://1ø4.198.2e3.36:8e -c 10 -n løø Running Iøø queries - Results - Successful calls Total time Average Fastest Slowest Amplitude Standard deviation RPS BSI le concurrency 3.3213 e. 3265 e. 3e68 e. 4335 e. 1267 ø.ø31545 løøx Done Status codes - code 5ø2 times . RPS : BSI: - Legend Request Per Second Boom Speed Index

 

 

테스트2 결과

 

- boom http://104.198.203.36 -c 1000 -n 10000

- 부하를 좀 더 주니, 차이가 난다

- code 500 = Internal Server Error 도 보인다.

- 서버 폭주에 의한 서비스의 일시적 중단, 서버의 이상

- 서버 스트립트의 오류

 

workers = 1

- 그나마 응답이 온게 5226번이고

- 그중에서 3번은 code 500

workers = 4

- 9796번 응답이 왔고, 온 경우는 모두 code 200

- 응답이 안온 개수는 204 개

- Results - Successful calls Total time Average Fastest Slowest Amplitude Standard deviation Code RPS BSI Code Status 5øø codes - 5226 22.4292 s 2.4120 s ø.5755 s 3.62e6 s 3.ø451 s e. 584851 Pretty good 5223 times. 3 times.

 

- Results - Successful calls Total time Average Fastest Slowest Amplitude Standard deviation Status codes - code 2øø 9796 24.1333 s 2.ø876 s ø.4522 s 15.7984 s 15.3463 s e. 951904 Pretty good 9796 times. RPS : BSI : - Legend Request Per Second Boom Speed Index

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Microsoft OneNote 2016에서 작성